Suspending translation look-aside buffer purge execution in a multi-processor environment

ABSTRACT

A method for operating translation look-aside buffers, TLBs, in a multiprocessor system. A purge request is received for purging one or more entries in the TLB. When the thread doesn&#39;t require access to the entries to be purged the execution of the purge request at the TLB may start. When an address translation request is rejected due to the TLB purge, a suspension time window may be set. During the suspension time window, the execution of the purge is suspended and address translation requests of the thread are executed. After the suspension window is ended the purge execution may be resumed. When the thread requires access to the entries to be purged, it may be blocked for preventing the thread sending address translation requests to the TLB and upon ending the purge request execution, the thread may be unblocked and the address translation requests may be executed.

BACKGROUND

The present disclosure relates to the field of digital computer systems,and more specifically, to a method for operating translation look-asidebuffers (TLBs).

Recent microprocessor architecture allows software to use so called“virtual” (or sometimes called “logical”) addresses to reference memorylocations. The memory access itself is done using a “physical” (orsometimes called “absolute”) address. To translate between the two,typically a TLB data structure is involved. The process of translatingis sometimes called Dynamic Address Translation (DAT), in particular inthe IBM z/Architecture.

TLB purge requests are executed atomically in that a purge request isnot suspended once it has been started and it cannot be suspended by TLBlookup/write requests. This avoids the problem that a TLB lookup may hiton a stale entry if a purge would have been suspended. However, purgesmay take up to 1000 p-clocks. In this time no translations can be donesince the purge-engine is blocking the TLB lookup/write pipeline. In aworst case scenario the core does not make any progress until the purgehas been finished.

SUMMARY

Various embodiments provide a method for operating translationlook-aside buffers, system and computer program product as described bythe subject matter of the independent claims. Advantageous embodimentsare described in the dependent claims. Embodiments of the presentinvention can be freely combined with each other if they are notmutually exclusive.

In one aspect, the disclosure relates to a method for operatingtranslation look-aside buffers, TLBs, in a multiprocessor system, themultiprocessor system comprising at least one core (processor core) eachsupporting at least one thread. The method comprises:

-   -   receiving a purge request for purging one or more entries in the        TLB;    -   determining if the thread requires access to an entry of the        entries to be purged;    -   in case the thread does not require access to the entries to be        purged:        -   starting execution of the purge request in the TLB;        -   setting a suspension time window;        -   suspending the execution of the purge during the suspension            time window;        -   executing address translation requests of the thread during            the suspension time window;        -   resuming the purge execution after the suspension window is            ended;    -   in case the thread requires access to the entries to be purged:        -   blocking the thread for preventing the thread sending            address translation requests to the TLB;        -   upon ending the purge request execution, unblocking the            thread and executing the address translations requests of            the thread.

In another aspect, the disclosure relates to a computer program productcomprising a computer-readable storage medium having computer-readableprogram code embodied therewith, the computer-readable program codeconfigured to implement all of steps of the method according topreceding embodiments.

In another aspect, the disclosure relates to a system for operatingtranslation look-aside buffers, TLBs, comprising at least one core eachhaving at least one thread. The system is configured for:

-   -   receiving a purge request for purging one or more entries in the        TLB;    -   determining if the thread requires access to an entry of the        entries to be purged;    -   in case the thread does not require access to the entries to be        purged:        -   starting execution of the purge request in the TLB;        -   setting a suspension time window if an address translation            request of the thread is rejected due to the TLB purge;        -   suspending the execution of the purge during the suspension            time window;        -   executing address translation requests of the thread during            the suspension time window;        -   resuming the purge execution after the suspension window is            ended;    -   in case the thread requires access to the entries to be purged:        -   blocking the thread for preventing the thread sending            address translation requests to the TLB;        -   upon ending the purge request execution, unblocking the            thread and executing the address translation requests of the            thread.

BRIEF DESCRIPTION OF THE DRAWINGS

In the following embodiments the disclosure is explained in greaterdetail, by way of example only, making reference to the drawings inwhich:

FIG. 1 depicts a computing environment that may be implemented by anexample of the present disclosure.

FIG. 2 depicts one example of a system controller coupled to a pluralityof central processors.

FIG. 3 is a flowchart of a method for operating a TLB in amultiprocessor system.

FIG. 4A is a flowchart of a method for controlling hardware purgesuspension.

FIG. 4B is a flowchart of a method for interrupting threads inaccordance with an example of the present disclosure

FIG. 4C is a flowchart of an example method for suspending the executionof the purge request.

FIG. 5 is a flowchart of a method for processing purge requests in avirtualized environment.

DETAILED DESCRIPTION

The descriptions of the various embodiments of the present disclosurewill be presented for purposes of illustration, but are not intended tobe exhaustive or limited to the embodiments disclosed. Manymodifications and variations will be apparent to those of ordinary skillin the art without departing from the scope and spirit of the describedembodiments. The terminology used herein was chosen to best explain theprinciples of the embodiments, the practical application or technicalimprovement over technologies found in the marketplace, or to enableothers of ordinary skill in the art to understand.

In one example, the multiprocessor system comprises two processor cores,wherein the purge request is received by one core from another core ofthe two cores. In another example, the purge request may be received bya thread of a core from another thread of the core. In another example,the multiprocessor system comprises more than two processor cores,wherein the purge request is broadcast by one core of the cores to theremaining cores.

A thread requiring access to an entry of the entries to be purged by thereceived purge request may be referred to as “honored thread”. A threadwhich does not require access to entries to be purged by the receivedpurge request may be referred to as “filtered thread”. An addresstranslation request is a request for translating a virtual address intoan absolute address using the TLB.

The term “quiesce” refers to the mechanisms used to force all processorsor cores or treads in a multi-processor system (e.g., those processorsthat have access to the data structure (e.g., table) being updated) tostop their activity.

The present method may provide better performance advantages in thepresence of purge requests. This is by contrast to conventional methodswhere all cores are suspended during purge requests regardless of theconfiguration status of the threads. With the present method the coremay make considerable progress until the purge has been finished.

According to one embodiment, the at least one core supports a secondthread, in case the first thread does not require access to the TLBentries to be purged and the second thread requires access to an entryto be purged, the method further comprises, before starting theexecution of the purge request at the TLB: blocking both the first andsecond threads for preventing them sending requests to the TLB; in casethe purge request has started by both the first and second thread,unblocking the first thread. This embodiment may enable at least part ofthreads to progress and therefore avoids interrupting all threads. Thetwo threads are both blocked in order to make use of a simplifiedarchitecture of the core. In another example, the second thread may bepart of another core of the multiprocessor system.

In another embodiment, in case the first thread requires access to atleast an entry of the entries to be purged and the second thread doesnot require access to the entries to be purged. The method furthercomprises: upon the blocking of the first thread, starting execution ofthe purge request at the TLB; setting a suspension time window if anaddress translation request by the second thread is rejected due to theTLB purge; suspending the execution of the purge during the suspensiontime window; executing address translation requests of the second threadduring the suspension time window; resuming the purge execution afterthe suspension window is ended. This embodiment may enable at least partof threads to progress and therefore avoids interrupting all threads.

According to one embodiment, the determining if the thread requiresaccess to an entry of the entries to be purged is performed based on acurrent state of the thread, the method further comprising before thepurge request ends, maintaining the state of the thread un-changed. Thedetermining if the thread requires access to an entry of the entries tobe purged may additionally be based on a current state of the threadthat sent the purge request. This may for example be performed bychecking the context of the thread against the context information sentwith the purge request.

According to one embodiment, the method further comprising in responseto receiving an assignment request for assigning the thread to a processrequiring access to the TLB, wherein the maintaining comprises blockingthe assignment request.

For example, as long as the purge request is active these assignmentrequests are blocked. The purge request is received from another thread.The other thread may send the purge request as part of an overallpurging process that may be executed in different components of themultiprocessor system. For example, for updating tables such as pagetables, the other thread may send the purge request such that thereceiving thread may adapt or update the local TLB accordingly. Thisoverall process may have a given execution lifetime which is the periodfrom the start to the end of the overall process. The execution of thepurge request at the TLB is performed during a time period. Thus, in oneexample the purge request is referred as being an active purge requestduring the whole execution lifetime. For example, for indicating thatthe purge request is active the purge request may be set to a pendingsate in the multiprocessor system during the execution lifetime. But if,in another example, the purging at the TLB takes longer than the purgerequest is pending in the system (e.g. since it gets suspended manytimes) the purge request is active as long as the purge is active at theTLB (e.g. during the time period).

These embodiments may prevent changing the state of a filtered thread tobecome a honored thread which may render the architecture even morecomplex.

According to one embodiment, the assignment request is received from aStart Interpretive Execution (SIE) component of the multiprocessorsystem for assigning the thread to a virtual processing unit (PU). Thisembodiment may seamlessly be integrated in exiting virtualizedenvironments. For example, although the thread in a current state is afiltered thread as it serves an old guest it may now become honoredthread by a new guest. So, if the new guest would be allowed, a hit onstale entries may happen. This may be prevented by the present method.

According to one embodiment, blocking the thread is performed usingfirmware instructions. In one example, the firmware instructions maycomprise millicode instructions.

According to one embodiment, the method further comprises providing abranch point having two states, wherein blocking the thread comprisessetting the branch point to the first state, and using firmwareinstructions for reading the state of the branch point for performingthe blocking, and upon ending the purge request execution, setting thebranch point to the second state; using the firmware instructions forreading the second state of the branch point for performing theunblocking. The branch point provides a hardware interface to thefirmware instructions. The state of the branch point is read by thefirmware instructions, and based on the state that has been read thethread (which is determined to be honored thread) may be blocked.

According to one embodiment, the method further comprises providinganother branch point having two states, wherein blocking the assignmentrequest comprises setting the other branch point to a state of the twostates, and using firmware instructions for reading said state of thebranch point for performing the blocking of the assignment request.

According to one embodiment, wherein the setting of the suspension timewindow is performed in response to an address translation request of thethread being rejected due to the TLB purge. The TLB purging refers tothe execution of the TLB purge request in the TLB. In other terms, if atranslation request comes in while a purge is running the translationrequest gets rejected in the first place since the TLB pipeline is usedby the purge request. This reject is used to put a running purge requestinto the suspend state. The suspend state is not reached immediately andmay take a while. A rejected request gets periodically reissued until itgets finally accepted. Once the reissued translation request falls intothe suspension window it can be accepted since the TLB pipeline is notoccupied by the purge request anymore.

According to one embodiment, the rejected address translation request isrecycled during a recycling time window, the recycling time window issmaller than the suspension time window, the executing of the addresstranslation requests of the thread comprises executing the recycledaddress translation request.

According to one embodiment, the method further comprises programmingthe suspension time window.

According to one embodiment, setting the suspension time windowcomprises providing a level signal having a predefined activation timeperiod during which the level signal is active, wherein the suspensiontime window is the activation time period. For example, the level signalmay be carried by a level sensitive LSU control line (LSU stands forload and store unit of the core). As long as the control line is activethe purge request is suspended. This feature may be advantageous whenused for translation requests issued in bursts.

FIG. 1 depicts a computing environment 100 that may be implemented by anexample of the present disclosure. Computing environment 100 is amultiprocessor system which may be based, for instance, on thez/Architecture offered by International Business Machines Corporation.

As one example, computing environment 100 includes a central processorcomplex (CPC) 102 coupled to a system controller 120. Central processorcomplex 102 includes, for instance, one or more partitions 104 (e.g.,logical partitions LP1-LPn), one or more central processors 106 (e.g.,CP1-CPm), and a first-level hypervisor 108 (e.g., a logical partitionmanager), each of which is described below.

Each logical partition 104 is capable of functioning as a separatesystem. That is, each logical partition can be independently reset,initially loaded with an operating system, if desired, and operate withdifferent programs. An operating system, hypervisor or applicationprogram running in a logical partition appears to have access to a fulland complete system, but, only a portion of it is available. Acombination of hardware and Licensed Internal Code (commonly referred toas firmware, microcode or millicode) keeps a program in a logicalpartition from interfering with a program in a different logicalpartition. This allows several different logical partitions to operateon a single or multiple physical processors in a time sliced manner. Asecond-level hypervisor can run in a partition 104 and provide the samefunction, such as transparent time-slicing of resources between multipleoperating systems (e.g. OS1-OSx running in virtual machines VM1-VMx 105)and isolation of operating systems from one another, within that logicalpartition.

In this particular example, logical partition 1 (LP1) 130 has a residentoperating system 110 and logical partition 2 (LP2) 131 runs asecond-level hypervisor2 109 which in turns creates virtual machines 141and 142 each of which runs its own resident operating systems 111 and112. Any number of the logical partitions may run a second-levelhypervisor. In one example, hypervisor2 109 is the z/VM hypervisor,offered by International Business Machines Corporation. In addition, theresident operating systems running in the various logical partitions maydiffer and, when running under a second-level hypervisor, the residentoperating systems within a single partition may also differ. In oneexample, operating system 110 is the z/OS operating system, which isoffered by International Business Machines Corporation. In anotherembodiment, operating systems 111 and 112 are Linux.

Central processors 106 are physical processor resources that areallocated to the logical partitions. For instance, a logical partition 1(LP1) 130 includes one or more logical processors, each of whichrepresents all or a share of physical processor resources 106 allocatedto the partition. The logical processors of a particular partition 104may be either dedicated to the partition, so that the underlyingprocessor resource is reserved for that partition; or shared withanother partition, so that the underlying processor resource ispotentially available to another partition. When a second-levelhypervisor2 109 is running in logical partition 2 (LP2) 131, it canprovide the same virtualization of resources provided by hypervisor1 tological partitions 104 to the operating systems 111 and 112 running invirtual machines 141, 142 within that partition. As at the first level,each virtual machine may include multiple virtual processors. The term“virtual CPU” is used herein to refer generically to a logical orvirtual processor.

Logical partitions 104 are managed by hypervisor 108 and 109 implementedby microcode running on processors 106. Logical partitions 104 andhypervisor 108 each comprise one or more programs residing in respectiveportions of central storage associated with the central processors. Oneexample of hypervisor 108 is the Processor Resource/Systems Manager(PRISM), offered by International Business Machines Corporation.

System controller 120, which is coupled to the central processorcomplex, includes centralized logic responsible for arbitrating betweendifferent processors issuing requests. For instance, when systemcontroller 120 receives a quiesce request, it determines that therequester is the initiating processor for that request and that theother processors are receiving processors; it broadcasts messages; andotherwise, handles requests.

For example, when a second-level hypervisor 109 is running in apartition and is running a program in a virtual machine, thesecond-level hypervisor is referred to as guest1 and the program runningin its virtual machine as guest2.

FIG. 2 depicts one example of a system controller 200 coupled to aplurality of central processors (CPUs) or cores 201 (such as CP1-CPm).In this example, two cores CPx and CPy are depicted. However, it will beunderstood that more than two processors may be coupled to systemcontroller 200.

System Controller 200 includes various controls including, for instance,system serialization controls 202. The system serialization controls 202are used to ensure that operations that are to be serialized, such asInvalidate Page Table Entry (IPTE), Invalidate DAT Table Entry (IDTE),Set Storage Key Extended (SSKE), or Compare and Swap and Purge (CSP andCSPG) instructions, are serialized, such that only one such instructionis in progress at one time in the computing environment. It alsomonitors the sequence of events for that operation.

System controller 200 is coupled to each core 201 via variousinterfaces. For instance, an interface 204 to the controller 200 is usedby the Licensed Internal Code in a central processor to send “control”commands, which specify an action to be taken, and to send “sense”commands, which return information from the controller 200. Anotherinterface is a response bus 206, which is used to return informationfrom the controller 200 for the “sense” commands. The response bus 306is also used to communicate command status for “control” commands, andmay be set from a plurality of sources within the controller 200,including the system serialization controls 202. A core 201 can use thisinterface to sense the state of the system serialization controls 202 insystem controller 200.

A further interface is interface 208, which provides commands totranslator controls 212 of core 201. Translator controls 212 processcommands, in response to the signals. In one example, translatorcontrols 212 process commands that affect one or more buffers, such asTranslation Look-aside Buffers (TLBs) 213 and 215 andAccess-Register-Translation Look-aside Buffers (ALBs) 214.

In addition to translator controls 212, core 201 includes various othercontrols, including, for instance, asynchronous interruption controls220 and execution controls 222. When the translator controls 212 receivea quiesce purge request (also referred to as fast-quiesce (FQUI) purgerequest) from the controller 202, the translator controls 212 processthe request in accordance with at least part of the present method fordetermining actions to be performed at this core 201. These actions maybe sent to the asynchronous interruption controls 220. An action of theactions may for example comprise an interruption to core 201. Inresponse to this action, asynchronous interrupt controls 220 cause aninternal fast-quiesce interruption 226 to be pending in the receivingprocessor, which in turn, causes execution controls 222 to suspendprogram instruction processing, at the next interruptible point.

The core 201 may comprise at least two translation lookaside buffers ofwhich a first one (TLB1) 313 is a first level buffer and a second one(TLB2) 315 is a second level translation lookaside buffer arranged tofeed said first one with address information in case of a missingaddress of the first one. For example, the address translation tables inmemory may be a multi-tier structure. For example, for a two-tier table,the first-level table, called a segment table, contains entries, whicheach map a MB of memory by point to a second-level table, called a pagetable, which contains 256 entries mapping 4 KB of memory. The TLB2 mayhave two types of entries: 1 MB segments and individual 4 KB pages. Whena translation is not available in first-level TLB (TLB1), TLB2 issearched for a 4 KB page entry that provides the required translation.If not, then TLB2 is searched for a segment entry for the segmentcontaining the address to be translated. If such an entry is found, thenthe translation using the tables in memory is short-circuited becausethe appropriate page table can be accessed directly without having toaccess the segment table in memory. And TLB1 may comprise a2-dimensional array of entries, e.g., 32 entries long and 4 entrieswide. Each entry contains a virtual address that was translated and theabsolute address that it translated to.

As illustrated in FIG. 2, each core 201 may support one or more threads240. Each thread 240 has an independent context or state defined forexample by program counter, registers, stack space of the core 201. Forexample, each thread may require a means for obtaining instruction data.This may consist of an engine to fetch instructions from cache orembedded memory which is followed by instruction decode hardware. Forexample, instructions for a thread may be fetched by an instructionfetch unit of the thread and sent by an instruction decoder and resourceinterlock to the execution controls 222.

For example, a thread 240 may be assigned to a given virtual processingunit via a SIE component of the multiprocessor system 100. Purgerequests may for example be submitted by guest virtual machines andreceived at the thread 240.

FIG. 3 is a flowchart of a method for operating a translation look-asidebuffer, TLB (e.g. TLB2 215) in a multiprocessor system e.g. 100.

In step 301, a purge request may be received. The purge request is forpurging one or more entries in the TLB2 315. The purge request comprisesa quiesce request in order to quiesce or interrupt the core 201. Thepurge request may for example be received by translations controls 212at receiving core CPx from another core CPy. In this example of FIG. 3,receiving core CPx supports a single thread 240. The other core CPy maytrigger the purge request in response to receiving the request from aguest such as guest two level machine. The purge request may for examplebe first received at the system controller 200 and may then be sent bysystem serialization controls 202 to the translator controls 212 of thecore CPx. For example, the purge request may be received from aprocessor operating at the guest2 level. In one example, the two coresCPx and CPy may run in the same guest2 multi-processor configuration.

In step 303, the translator controls 212 may determine if the thread 240supported by core CPx requires access to an entry of the entries to bepurged of the TLB (e.g. TLB2 215). This may for example be performed bychecking the context of the thread 240 against the context informationsent with (or comprised in) the purge request. This may also beperformed by further checking the state or context of the thread thatsent the purge request. For example, this context compare may indicatethat the thread has translation requests to be performed using TLB (e.g.TLB2 215) entries affected by the received purge request. The purgerequest may for example be received or may be ordered to be executedbefore executing the translation requests and thus the translationrequests may have to be performed after execution of the purge requestif they require access to the entries to be purged.

In case (inquiry 305) the thread 240 does not require access to theentries to be purged steps 307-315 are executed otherwise steps 317-321are executed.

In step 307, the execution of the purge request may start at the TLB.For example, the purge request may be sent by Fast-Qui Pending block 226to the TLB for execution.

In step 309, a suspension time window may be set. Step 309 is set afterstep 307. For example, step 309 may be performed if the thread'stranslation request gets rejected due to the TLB purge. If a translationrequest comes in while the purge request is running, the translationrequest gets rejected in the first place since the TLB pipeline is usedby the purge request. This reject is used to put the running purgerequest into a suspend state. The purge stays in this suspended stateuntil the suspension time window has been elapsed. During this time apurge engine does not occupy the TLB pipeline (e.g. the TLB2 pipeline)so that incoming translation requests can be processed during thesuspension time window.

In step 311, the execution of the TLB purge is suspended during thesuspension time window such that translation requests of the thread 240may be started in step 313 during the suspension time window. Forexample, the translation requests of the thread 240 may not be rejectedduring the suspension time window.

In step 313, a translation may be started if it comes in while the purgeengine is suspended (311) (e.g. the execution of the TLB purge issuspended by suspending the purge engine that controls the TLB purge).

In step 315, the purge execution may be resumed after the suspensionwindow is ended. For example, the suspension time window may be definedsuch that all translation requests in the current state of the thread240 can be executed during the suspension time window. In one example,steps 309-315 may be repeated if other translation requests get rejectedafter resuming the purge execution in the TLB by the filtered thread.

In case the thread 240 requires access to the entries to be purged, thethread 240 may be blocked in step 317 for preventing the thread 240sending translation requests to the TLB 215. This may for example beperformed by using a firmware/millicode routine at the core 201 forstopping/blocking the translation requests of the thread 240.

And upon ending the purge request execution at the TLB 215, the threadmay be unblocked in step 319 and the translation requests of the thread240 may be executed in step 321 (e.g. the translation requests may beissued again). The firmware or millicode routine prevents translationrequests from being issued. From a purge suspension point of view areject will put the purge engine into the suspension state. So thatmeans that a honored thread must not issue translation requests beforethe end of the purge request execution.

For example, if a translation request comes in while the purge requestis running the translation request gets rejected since the TLB pipelineis used by the purge request. A rejected request gets periodicallyreissued until it gets finally accepted. After the honored thread hasbeen unblocked translation requests can be processed again in step 321.

FIG. 4A is a flowchart of a method for controlling hardware purgesuspension e.g. in multiprocessor system 100.

In step 401 a purge request is received. The purge request may forexample be received at core CPx 201. For example, the request may bereferred to as FQUI purge request. In this example, receiving core CPxsupports two threads TH0 and TH1. The purge request is for purging oneor more entries in a TLB (e.g. TLB2 215) of the receiving core CPx.

Upon receiving the purge request, it may be determined (inquiry 403) ifthe two threads TH0 and TH1 require access to an entry of the entries tobe purged. This may for example be determined by translator controls212. A thread requiring access to an entry of the entries to be purgedby the received purge request may be referred to as honored threadotherwise it may be referred to as a filtered thread.

In case (inquiry 403) both threads TH0 and TH1 do not require access toentries to be purged steps 405-408 may be executed. In case (inquiry403) at least one thread (TH0 and/or TH1) requires access to at leastone entry of entries to be purged steps 409-435 and 408 may be executed.

In step 405, the purge request may start at the TLB 215 (the TLB purgingstarts). Upon starting the TLB purging method of FIG. 4C may be executed(at point B of the diagram). A check may be performed if the TLB purgingends (inquiry 407), which indicates the end of the purge request in step408

In step 409, the two threads TH0 and TH1 may be blocked such that thethreads TH0 and TH1 are prevented from sending address translationrequests to the TLB. For that, for example, asynchronous interruptcontrols 220 may cause the setting of a FQUI interrupt for both threadsTH0 and TH1 and the internal fast-quiesce interruption 226 to be pendingfor both threads TH0 and TH1. This further causes execution controls 222to suspend program instruction processing, at the next interruptiblepoint for each of the threads TH0 and TH1. Executing of step 409triggers the execution of the method of FIG. 4B (at point A of thediagram).

In step 411, a branch point having two states may be set via the FQUIinterrupt for each of the two threads TH0 and TH1.

In a first state of the branch point the thread (TH0/TH1) branchesaround the branch point into a blocking state for blocking translationrequest to the TLB. And, in a second state of the branch point thethread branches around the branch point into an unblocking state forenabling translation requests submission to the TLB by the thread.

It may be checked (inquiry 413) if both threads 413 have reached therespective interruption points which is referred to in the figure as acheck if the received FQUI purge request is started at the TH0 and TH1.In case, both threads TH0 and TH1 have reached the interruption point,the TLB purging may start in step 415 at the TLB 215. Upon starting theTLB purging method of FIG. 4C may be executed (at point B of thediagram).

Upon starting the TLB purging in step 415, it may be determined(inquiries 417 and 425) which of the threads TH0 and TH1 is a honoredthread and which one is filtered.

In case (inquiry 417) TH0 is a filtered thread and TH1 is a honoredthread, the branch point may be reset in step 419 for the thread TH0,thereby unblocking the thread TH0 such that translation requests may besent by thread TH0. And only in case (inquiry 421) the TLB purge is donethat the branch point is reset in step 423 for the thread TH1 therebyunblocking the thread TH1 such that translation requests may be sent bythread TH1.

In case (inquiry 425) TH1 is a filtered thread and TH0 is an honoredthread, the branch point may be reset in step 427 for the thread TH1,thereby unblocking the thread TH1 such that translation requests may besent by thread TH1. And only in case (inquiry 429) the TLB purge is donethat the branch point is reset in step 431 for the thread TH0 therebyunblocking the thread TH0 such that translation requests may be sent bythread TH0.

In case none of the threads TH0 and TH1 is a filtered thread, only incase (inquiry 433) the TLB purge is done that the branch point is resetfor both threads TH0 and TH1 in step 435.

FIG. 4B is a flowchart of a method for interrupting the threads TH0 andTH1 in accordance with an example of the present disclosure.

FIG. 4B describes the setting of the FQUI interrupt per thread of thetwo threads TH0 and TH1. The FQUI interrupt may be set for the thread instep 441.

In case (442) the FQUI interrupt is taken by the thread, a millicoderoutine of the receiving core CPx may be used in step 443 to block orprevent the thread to send translations requests to the TLB. This isreferred to as the thread has entered the millicode.

After being blocked by the millicode, it may be determined (inquiry 444)if the thread is a filtered thread. In case, the thread is a filteredthread, the FQUI request may start at the thread in step 445. Uponstarting the FQUI request at the thread, it may be determined (inquiry446) if the branch point is reset for the thread. In case, the branchpoint is reset for the thread, the millicode routine may be configuredsuch that it does not block the translation requests of the thread instep 450. This is also referred to as the thread is leaving themillicode.

Upon executing step 450, the execution of the instructions of the threadmay be resumed in step 451.

In case, the thread is a not a filtered thread, the thread is serializedin step 447 and steps 448-451, wherein steps 448 and 449 are similar tosteps 445 and 446.

FIG. 4C is a flowchart of an example method for suspending the executionof the purge request. The method of FIG. 4C may be executed per threadTH0 and TH1.

In step 461, a suspend status flag may be set to FALSE to indicate thatthe execution of the purge request for an entry having a 1st address isnot suspended.

And it may be determined (inquiry 463) if the purge of the entry havingthe 1st address is done. In case, the purge of the TLB is not done yetfor the 1st address, and a processor request such as an addresstranslation request (referred to as “xlat request”) is received (464)e.g. from the tread 240 the suspend status flag may be set to TRUE instep 465 and the processor request is rejected.

In case (inquiry 463) the purge of the entry having the 1st address isdone, and in case (inquiry 466) there are still additional one or moreentries to be purged, it may be checked (inquiry 468) if the suspendstatus flag is set to TRUE or not.

In case (inquiry 468) the suspend status flag is set to TRUE, and incase (inquiry 469) the thread is a filtered thread, it may be determinedif (inquiry 470) a processor request such as xlat request is receivedfrom the thread.

In case a processor request is received (inquiry 470) from the thread,the request is accepted in step 471 such that it can for example beexecuted on TLB 215 and thereafter a suspend counter is incremented instep 472. The suspend counter may for example be an integer value thatis initiated to 0, and the increment of the suspend counter is by 1.

In case a processor request is not received (inquiry 470), step 472 maybe executed.

And it may be determined if (inquiry 473) the suspend counter hasreached a predefined threshold value.

In case (inquiry 473) the suspend counter has not reached the predefinedthreshold value, steps 470-473 may be repeated.

In case (inquiry 473) the suspend counter has reached the predefinedthreshold value, steps 474-477 may be executed. Steps 474-477 aresimilar to steps 461-465.

In case (inquiry 468) the suspend status flag is set to FALSE, steps475-477 may be executed.

FIG. 5 is a flowchart of a method for blocking SIE requests whileprocessing the FQUI purge request 501 in accordance with an example ofthe present disclosure.

It may be determined (inquiry 503) if the purging of the TLB is done. Incase, the purge of the TLB is not done yet, and in case (inquiry 505) aSIE request has been received to change the configuration associatedwith the thread a branch point state may be set in step 507 such thatthe SIE request that changes the configuration of the thread areblocked. In the guest2 environment, hypervisor2 (e.g. 109) may specifythe origin of an area called the System Control Area (SCA). An exampleof the SIE request referred to in FIG. 5 is an SIE request for changingZONE/SCAO. SCAO stands for SCA Origin. The SCAO may be changed within agiven zone (ZONE) or virtual machine.

In case (inquiry 503) the purging of the TLB is done, it may bedetermined (inquiry 508) if the FQUI request is still pending. Forexample, it may be determined the internal fast-quiesce interruption 226of the thread is still pending.

In case (inquiry 508), the FQUI request is still pending, and in case(inquiry 509) a SIE request has been received to change theconfiguration associated with the thread a branch point state may be setin step 510 such that the SIE request that changes the configuration ofthe thread are blocked.

In case (inquiry 508), the FQUI request is not pending the branch pointmay be reset in step 511 such that the SIE requests may be enabled.

Aspects of the present invention are described herein with reference toflowchart illustrations and/or block diagrams of methods, apparatus(systems), and computer program products according to embodiments of theinvention. It will be understood that each block of the flowchartillustrations and/or block diagrams, and combinations of blocks in theflowchart illustrations and/or block diagrams, can be implemented bycomputer readable program instructions.

The present invention may be a system, a method, and/or a computerprogram product. The computer program product may include a computerreadable storage medium (or media) having computer readable programinstructions thereon for causing a processor to carry out aspects of thepresent invention.

The computer readable storage medium can be a tangible device that canretain and store instructions for use by an instruction executiondevice. The computer readable storage medium may be, for example, but isnot limited to, an electronic storage device, a magnetic storage device,an optical storage device, an electromagnetic storage device, asemiconductor storage device, or any suitable combination of theforegoing. A non-exhaustive list of more specific examples of thecomputer readable storage medium includes the following: a portablecomputer diskette, a hard disk, a random access memory (RAM), aread-only memory (ROM), an erasable programmable read-only memory (EPROMor Flash memory), a static random access memory (SRAM), a portablecompact disc read-only memory (CD-ROM), a digital versatile disk (DVD),a memory stick, a floppy disk, a mechanically encoded device such aspunch-cards or raised structures in a groove having instructionsrecorded thereon, and any suitable combination of the foregoing. Acomputer readable storage medium, as used herein, is not to be construedas being transitory signals per se, such as radio waves or other freelypropagating electromagnetic waves, electromagnetic waves propagatingthrough a waveguide or other transmission media (e.g., light pulsespassing through a fiber-optic cable), or electrical signals transmittedthrough a wire.

Computer readable program instructions described herein can bedownloaded to respective computing/processing devices from a computerreadable storage medium or to an external computer or external storagedevice via a network, for example, the Internet, a local area network, awide area network and/or a wireless network. The network may comprisecopper transmission cables, optical transmission fibers, wirelesstransmission, routers, firewalls, switches, gateway computers and/oredge servers. A network adapter card or network interface in eachcomputing/processing device receives computer readable programinstructions from the network and forwards the computer readable programinstructions for storage in a computer readable storage medium withinthe respective computing/processing device.

Computer readable program instructions for carrying out operations ofthe present invention may be assembler instructions,instruction-set-architecture (ISA) instructions, machine instructions,machine dependent instructions, microcode, firmware instructions,state-setting data, or either source code or object code written in anycombination of one or more programming languages, including an objectoriented programming language such as Smalltalk, C++ or the like, andconventional procedural programming languages, such as the “C”programming language or similar programming languages. The computerreadable program instructions may execute entirely on the user'scomputer, partly on the user's computer, as a stand-alone softwarepackage, partly on the user's computer and partly on a remote computeror entirely on the remote computer or server. In the latter scenario,the remote computer may be connected to the user's computer through anytype of network, including a local area network (LAN) or a wide areanetwork (WAN), or the connection may be made to an external computer(for example, through the Internet using an Internet Service Provider).In some embodiments, electronic circuitry including, for example,programmable logic circuitry, field-programmable gate arrays (FPGA), orprogrammable logic arrays (PLA) may execute the computer readableprogram instructions by utilizing state information of the computerreadable program instructions to personalize the electronic circuitry,in order to perform aspects of the present invention.

Aspects of the present invention are described herein with reference toflowchart illustrations and/or block diagrams of methods, apparatus(systems), and computer program products according to embodiments of theinvention. It will be understood that each block of the flowchartillustrations and/or block diagrams, and combinations of blocks in theflowchart illustrations and/or block diagrams, can be implemented bycomputer readable program instructions.

These computer readable program instructions may be provided to aprocessor of a general purpose computer, special purpose computer, orother programmable data processing apparatus to produce a machine, suchthat the instructions, which execute via the processor of the computeror other programmable data processing apparatus, create means forimplementing the functions/acts specified in the flowchart and/or blockdiagram block or blocks. These computer readable program instructionsmay also be stored in a computer readable storage medium that can directa computer, a programmable data processing apparatus, and/or otherdevices to function in a particular manner, such that the computerreadable storage medium having instructions stored therein comprises anarticle of manufacture including instructions which implement aspects ofthe function/act specified in the flowchart and/or block diagram blockor blocks.

The computer readable program instructions may also be loaded onto acomputer, other programmable data processing apparatus, or other deviceto cause a series of operational steps to be performed on the computer,other programmable apparatus or other device to produce a computerimplemented process, such that the instructions which execute on thecomputer, other programmable apparatus, or other device implement thefunctions/acts specified in the flowchart and/or block diagram block orblocks.

The flowchart and block diagrams in the Figures illustrate thearchitecture, functionality, and operation of possible implementationsof systems, methods, and computer program products according to variousembodiments of the present invention. In this regard, each block in theflowchart or block diagrams may represent a module, segment, or portionof instructions, which comprises one or more executable instructions forimplementing the specified logical function(s). In some alternativeimplementations, the functions noted in the block may occur out of theorder noted in the Figures. For example, two blocks shown in successionmay, in fact, be executed substantially concurrently, or the blocks maysometimes be executed in the reverse order, depending upon thefunctionality involved. It will also be noted that each block of theblock diagrams and/or flowchart illustration, and combinations of blocksin the block diagrams and/or flowchart illustration, can be implementedby special purpose hardware-based systems that perform the specifiedfunctions or acts or carry out combinations of special purpose hardwareand computer instructions.

What is claimed is:
 1. A system for operating translation look-asidebuffers, TLBs, comprising at least one core each having at least onethread, the system being configured for: receiving a purge request forpurging one or more entries in the TLB; determining if a thread requiresaccess to an entry of the entries to be purged; when the thread does notrequire access to the entries to be purged: starting execution of thepurge request in the TLB; setting a suspension time window; suspendingthe execution of the purge during the suspension time window; executingaddress translation requests of the thread during the suspension timewindow; resuming the purge execution after the suspension window isended.
 2. The system of claim 1, the at least one core supporting asecond thread, in case a first thread does not require access to the TLBentries to be purged and the second thread requires access to an entryto be purged, the system being further configured for before startingthe execution of the purge request at the TLB: blocking both the firstand second threads for preventing them sending requests to the TLB; whenthe purge request has started at both the first and second threads,unblocking the first thread.
 3. The system of claim 1, wherein thesetting of the suspension time window is performed in response to anaddress translation request of the thread being rejected due to the TLBpurge.
 4. The system of claim 3, wherein the rejected addresstranslation request is recycled during a recycling time window, whereinthe recycling time window is smaller than the suspension time window,wherein the executing of the address translation requests of the threadcomprises executing the recycled address translation request.
 5. Thesystem of claim 1, setting the suspension time window comprisingproviding a level signal having a predefined activation time periodduring which the level signal is active, wherein the suspension timewindow is the activation time period.
 6. A system for operatingtranslation look-aside buffers, TLBs, comprising at least one core eachhaving at least one thread, the system being configured for: receiving apurge request for purging one or more entries in the TLB; determining ifa thread requires access to an entry of the entries to be purged; whenthe thread requires access to the entries to be purged: blocking thethread for preventing the thread sending address translation requests tothe TLB; upon ending the purge request execution, unblocking the threadand executing the address translation requests of the thread.
 7. Thesystem of claim 6, the at least one core supporting a second thread,when a first thread requires access to at least an entry of the entriesto be purged and the second thread does not require access to theentries to be purged, the system being further configured for: upon theblocking of the first thread starting execution of the purge request atthe TLB; setting a suspension time window if an address translationrequest by the second thread is rejected due to the TLB purge;suspending the execution of the purge during the suspension time window;executing address translation requests of the second thread during thesuspension time window; resuming the purge execution after thesuspension window is ended.
 8. The system of claim 6, the determining ifthe thread requires access to an entry of the entries to be purged isperformed based on a current state of the thread, the system beingfurther configured for before the purge request ends, maintaining thestate of the thread un-changed.
 9. The system of claim 8, being furtherconfigured for in response to receiving an assignment request forassigning the thread to a process requiring access entries to be purged,blocking the assignment request.
 10. The system of claim 9, furthercomprising providing a branch point having two states, wherein blockingthe thread comprises setting the branch point to the first state, andusing firmware instructions for reading the state of the branch pointfor performing the blocking, and upon ending the purge requestexecution, setting the branch point to the second state; using thefirmware instructions for reading the second state of the branch pointfor performing the unblocking.
 11. The system of claim 10, furthercomprising providing another branch point having two states, whereinblocking the assignment request comprises: setting the other branchpoint to a state of the two states, and using firmware instructions forreading said state of the branch point for performing the blocking ofthe assignment request.
 12. The system of claim 8, wherein theassignment request is received from a Start Interpretive Execution (SIE)component of the multiprocessor system for assigning the thread to avirtual processing unit (PU).
 13. The system of claim 6 wherein blockingthe thread is performed using firmware instructions.
 14. A computerprogram product comprising a computer-readable storage medium havingcomputer-readable program code embodied therewith, the computer-readableprogram code configured to implement the steps of: receiving a purgerequest for purging one or more entries in the TLB; determining if athread requires access to an entry of the entries to be purged; when thethread does not require access to the entries to be purged: startingexecution of the purge request in the TLB; setting a suspension timewindow; suspending the execution of the purge during the suspension timewindow; executing address translation requests of the thread during thesuspension time window; resuming the purge execution after thesuspension window is ended.
 15. The computer program product of claim 14wherein the at least one core supporting a second thread, when a firstthread does not require access to the TLB entries to be purged and thesecond thread requires access to an entry to be purged, the stepsfurther comprises, before starting the execution of the purge request atthe TLB: blocking both the first and second threads for preventing themsending requests to the TLB; when the purge request has started at boththe first and second threads, unblocking the first thread.
 16. Thecomputer program product of claim 15 wherein the setting of thesuspension time window is performed in response to an addresstranslation request of the thread being rejected due to the TLB purge.